Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d1 / bastips2.arc / BASICNTS.TXT < prev next >

Wrap

Text File | 1988-11-30 | 43.9 KB | 993 lines

Safe Zones in IBM BASIC (COMPUTE! Magazine July 1986) There is a way to store a few characters or flags in the PC's memory that will survive the BASIC RUN command. BASIC's CLEAR command gives you the ability to create a safe area of RAM of almost any size. Besides deleting all variables, CLEAR controls the amount of memory available to BASIC. By adding a command and a parameter to the CLEAR command, you can make the BASIC workspace smaller than usual, reserving the extra memory for yourself. The workspace is initially 65,536 bytes but it's easy to reserve some memory at the top of that space. Use this format: CLEAR ,workspace where workspace is a number less than 65536. To calculate the correct value, subtract from 65536 the number of bytes you want to protect. For instance, the command, CLEAR ,65280 reserves the last 256 bytes (65536 - 256 = 65280) of BASIC workspace for your use. When you type RUN after a CLEAR statement like this, the size of the workspace is reset to its default but the data in the reserved area is not affected. As long as the next program begins with a similar CLEAR statement, it can PEEK into the reserved area and find the values that the previous program POKEd there. Here's a simple program that stores some values in a 256-byte reserved area: 10 CLEAR ,65280 20 FOR A=0 TO 255 30 POKE A+65280,A 40 NEXT After you run the program, enter and run this program to read the stored values back: 10 CLEAR ,65280 20 FOR A=0 TO 255 30 PRINT PEEK(A+65280) 40 NEXT ----------------------------------------------------------------- Selective BSAVE/BLOAD (PC Magazine Vol 5 No 13 July 1986 User-to-User) Most users who BSAVE and BLOAD BASICA screens do so a full screen at a time, but it can be very handy to do it in smaller pieces. The LITLBSAV.BAS program BSAVEs a little piece of the screen (three lines) and then lets the user BLOAD it back in various places up and down the screen. This technique works very well off a RAMdisk or hard disk but is slow when run from a floppy. Editor's Note: The program was modified so it BSAVEd three lines (a line of text with a blank line above and below) and let users move the BSAVEd block up and down the screen. (Including blank lines above and below the printed line effectively erases existing printed lines on-screen.) In line 120 the program determines whether the system is monochrome (where PEEK(1097)=7) or not, and in line 130 sets the segment to &HB800 for color or &HB000 for mono. Color systems offer four screen pages, 0 through 3. If you have a color system, you can increase the upper limit in line 200 to 3680 and make the text temporarily "disappear." The nice thing about this technique is that it lets you "pop" up text onto existing screens. However, it won't restore the existing part of the screen it covers over. Still, by BSAVEing portions of screens and BLOADing them at the appropriate locations, you save disk space adn make the BLOAD operation a little faster. Since color screen memory is not dual-ported (as mono memory is), you'll see "chatter" or "snow" while the BLOAD is occurring. Most snow is white, so by setting a white (7) background most of it is covered up. This will run slower on a disk system unless you hit the Up and Down Arrow keys rapidly enough to keep the floppy spinning constantly. These days you can buy slow hard disks for a lot less than $500. Or stock up on system RAM and try this in a RAMdisk. BSAVCALC.BAS calculates the offset and length for BSAVEs (and the offset for BLOADs) less than a full screen in size. The PC text screen memory is arranged so that each character takes up 2 bytes -- one representing the actual character, and one for the character's attribute. The default text screen is 80 characters wide, so each 80-wide lien in memory takes up 160 bytes. Color memory begins at segment &HB800, mono memory at &HB000. You tell BASICA which segment you want with the statement DEF SEG=&HB800 or DEF SEG=&HB000. BSAVE needs to know three things -- the filename it will use to store the screen on your disk, the "offset" (distance in bytes up from the segment specified by DEF SEG), and the length of the file to save. Line 1 goes from offset 0 to offset 159, line 2 from 160 to 319, etc. All BLOAD needs to know is the filename and offset, not the length. 100 'LITLBSAV.BAS 110 DEFINT A-Z:CLEAR:S$=STRING$(4,205) 120 DEF SEG=0:IF PEEK(1097)=7 THEN SG=&HB000 ELSE SG=&HB800 130 DEF SEG=SG:KEY OFF:SCREEN 0,0:COLOR 4,7,6:CLS:LOCATE 2,1,0 140 PRINT S$;" This BLOADs a line at a time (hit ";CHR$(24):" and "; 150 PRINT CHR$(25);" keys to move, or ESC to end) ";S$ 160 BSAVE "TEST.SCR",0,480:CLS:S=3680:GOTO 210 170 I$=INKEY$:IF I$="" THEN 170 ELSE IF I$=CHR$(27) THEN LOCATE 1,1:END 180 I=INSTR("HP",RIGHT$(I$,1)):IF I=0 OR LEN(I$)=1 THEN BEEP:GOTO 210 190 IF I=1 THEN IF S<0 THEN BEEP:GOTO 170 ELSE S=S-160:GOTO 210 200 IF S>3520 THEN BEEP:GOTO 170 ELSE S=S+160 210 BLOAD "TEST.SCR",S:GOTO 170 - - - - - 100 'BSAVCALC.BAS 110 DEF FNST$(Z)=MID$(STR$(Z),2+(Z<0)):Q$=CHR$(34):CLS 120 PRINT "Pick one: 1 - BSAVE 2 - BLOAD (1 or 2)" 130 I$=INKEY$:IF I$="" THEN 130 ELSE IF I$=CHR$(13) THEN END 140 IF INSTR("12",I$)=0 THEN 130 ELSE I=VAL(I$) 150 IF I=2 THEN B$="BLOAD " ELSE B$="BSAVE " 160 PRINT CHR$(30);B$;"information:";STRING$(20,32) 170 INPUT "Enter a start line from 1-25: ",S1 180 IF S1<1 OR S1>25 THEN BEEP:GOTO 170 190 IF I=2 THEN PRINT:PRINT "For line";S1:GOTO 230 200 INPUT "Enter a stop line from 1-25: ",S2 210 IF S2<1 OR S2>25 OR S2<S1 THEN BEEP:GOTO 200 220 PRINT:PRINT "For line(s)";S1;"to";S2 230 OFFSET=(S1-1)*160:LENGTH=(S2*160)-OFFSET 240 PRINT "Offset =";OFFSET:IF I=2 THEN 260 250 PRINT "Length =";LENGTH 260 PRINT "Syntax = ";B$;Q$;"filename";Q$;","; 270 PRINT FNST$(OFFSET);:IF I=2 THEN 290 280 PRINT ",";FNST$(LENGTH); 290 PRINT:PRINT:PRINT STRING$(40,61):PRINT:GOTO 120 ----------------------------------------------------------------- Value Added (PC Magazine Vol 5 No 13 July 1986 User-to-User) In the IBM BASICA documentation for VAL, the example at the bottom of the page correctly extracts the house number from an address: PRINT VAL("3408 SHERWOOD BLVD.") 3408 However, if the address happens to be "3408 E 9th Street," VAL returns the number 3048000000000, as it interprets the "E" as the exponential part of the number. This also occurs with a D. You can prevent trouble by putting periods after the E or D. PRINT VAL("3408 E. 9th Street") works properly. ----------------------------------------------------------------- Automatic IBM Screen Printing (COMPUTE! Magazine August 1986) You can add a Print Screen function to any program by POKEing a tiny machine language into a reserved space at the top of BASIC's memory area. The ML just executes INT5:RETF to call the Print Screen routine and returns to BASIC. When incorporating this routine into your program(s), the line with the CLEAR statement must be the first line in your program. Otherwise, any previously defined variables will be erased. Once the machine language is POKEd into memory, your program can execute the statement CALL PRTSC to make a printout. 100 CLEAR ,&HFFF0:PRTSC=&HFFF0 110 DEF SEG:FOR X=0 TO 2:READ N:POKE X+PRTSC,N:NEXT 120 DATA &HCD,&H05,&HCB 200 CALL PRTSC ----------------------------------------------------------------- Batch Files with IBM BASIC (COMPUTE! Magazine August 1986 by Lawrence H. Bannister) IBM users know that you can save time by using the batch commands of DOS to perform a sequence of DOS commands automatically. But the austere language of DOS provides only three variations of one simple IF statement and has no practical way at all of manipulating strings or performing arithmetic. It's difficult to write a batch file that creates neat screen displays, makes logical branches, allows user input, and traps errors. A more flexible technique is to call DOS commands or even batch files from with a BASIC program. This frees you from the limitations of batch files and takes advantage of the string and arithmetic functions of BASIC. You can call DOS from BASIC as often as you wish by using the SHELL command found in IBM BASICA. Although it is not documented, this command is implemented in version 2.1 or higher of DOS. Aside from a few small problems to be avoided, its possibilities are limited only by your imagination. To demonstrate some of these possibilities, the BASIC Batch Demo program below displays two menus of options, interprets the user's responses, and then calls a variety of DOS routines in several different ways. The Batch File for Demo is a short batch file that is required as part of this demonstration. When you run the BASIC program, it shows a menu offering four choices: MENU A: 1. Show system date 2. Show system time 3. Show system date and time 4. None of the above Enter your choice: When the user presses a key, the program checks to see if the keypress was 1, 2, 3, or 4, and if so, uses the SHELL command to call the appropriate DOS function: DATE, TIME, or the batch file that calls both DATE and TIME. When DOS returns control to BASIC, the program displays a second menu: MENU B: 1. Run Checkdisk 2. Show Disk Directory 3. None of the above Enter your choice: This is similar to the first menu, except this time the program calls a DOS function that requires a parameter to be passed to the DOS command line. The BASIC program asks the user for the necessary information, then concatenates the appropriate command-line string. Notice that the SHELL command can pass either a literal string, as done in the first menu, or a string variable, as in the response to the second menu. There are two considerations to keep in mind when using this technique. First, make sure your system has enough memory. Although DOS, BASICA, and your BASIC program can be loaded into a machine with as little as 64K of RAM, you won't have much memory left over to do anything very useful. At least 92K RAM is desireable, because DOS and BASICA together use about 90K if that much is available. You need still more memory if you also want to run a batch file that calls a lengthy program like EDLIN. Second, be sure not to create a sequence that is reentrant or recursive. For example, the result will be unpredictable if you BASIC program calls a batch file that, in turn, calls BASIC. Reentrant sequences of this nature are apt to cause a system crash that can be remedied only by turning off the power. A minor aggravation is that DOS scrolls 25 lines on the screen while BASIC scrolls only 24 lines due to the function key display on the 25th line. Furthermore, BASIC and DOS each maintain an independent pointer to the screen position of the cursor. These differences can cause BASIC PRINT statements to overwrite something that DOS has just printed. To avoid this problem, always start the BASIC program with the KEY OFF command to turn off BASIC's function key display. Then use a CLS command each time that DOS returns control to BASIC, or, as shown in the sequence following the second menu in the BASIC Batch Demo program, surround the SHELL commands with LOCATE 24,1 statements and two blank PRINT lines to ensure that both DOS and BASIC always start scrolling from the bottom of their own screens. BASIC Batch Demo Program: 1000 'Procedure Description 1010 'Clear screen and display a menu offering four choices 1020 'Wait for user response 1030 'If user response is not valid 1040 'Then : display error message and repeat the menu 1050 'Else : 1060 'Invoke the selected DOS function or Batch file 1070 'Clear screen and display a second menu 1080 'Wait for user response 1090 'If user response is not valid 1100 'Then : display error message and repeat the menu 1110 'Else : 1120 'Invoke the selected DOS function or program 1130 ' 1140 ' 1150 KEY OFF:CLS 1160 GOTO 1210 1170 ' 1180 PRINT 'Error message 1190 PRINT "* * * * * * * ILLEGAL RESPONSE ^ REDO" 1200 ' 1210 PRINT:PRINT "MENU A:" 'Display menu 1220 PRINT:PRINT "1. Show system date" 1230 PRINT:PRINT "2. Show system time" 1240 PRINT:PRINT "3. Show system date and time" 1250 PRINT:PRINT "4. None of the above" 1260 PRINT:PRINT:INPUT "Enter your choice: ",A$ 1270 ' 1280 IF A$="" THEN 1180 'Check response 1290 IF ASC(A$)<49 THEN 1180 1300 IF ASC(A$)>52 THEN 1180 1310 ' 1320 IF A$="1" THEN SHELL "DATE" 1330 IF A$="2" THEN SHELL "TIME" 1340 IF A$="3" THEN SHELL "PROG2" 1350 ' 1360 CLS 1370 GOTO 1410 1380 ' 1390 PRINT "* * * * * * * ILLEGAL RESPONSE ^ REDO" 1400 ' 1410 PRINT:PRINT "MENU B:" 1420 PRINT:PRINT "1. Run Checkdisk" 1430 PRINT:PRINT "2. Show Disk Directory" 1440 PRINT:PRINT "3. None of the above" 1450 PRINT:PRINT:INPUT "Enter your choice: ",A$ 1460 PRINT 1470 ' 1480 IF A$="" THEN 1390 1490 IF ASC(A$)<49 THEN 1390 1500 IF ASC(A$)>51 THEN 1390 1510 ' 1520 IF A$="3" THEN 1630 1530 IF A$="1" THEN B$="CHKDSK" 1540 IF A$="2" THEN B$="DIR" 1550 INPUT "Enter drive letter: ",C$ 1560 IF C$="" THEN 1550 1565 X=ASC(C$+CHR$(0)):IF X<65 OR X>66 THEN 1550 1570 D$=B$+LEFT$(C$,1)+":" 1580 LOCATE 24,1 1590 IF A$="1" THEN GOSUB 1710 1600 SHELL D$ 1610 PRINT:PRINT 1620 ' 1630 PRINT "End of BASICA program, returning to SYSTEM" 1640 PRINT 1650 PRINT TAB(20) "Normally would return to SYSTEM here," 1660 PRINT TAB(20) "but for debug and demo purposes the" 1670 PRINT TAB(20) "program will restart after a delay" 1680 FOR I=1 TO 5000:NEXT I:RUN 1690 ' 1700 ' 1710 PRINT 1720 PRINT "WARNING: You will get error message `Bad command ...'" 1730 PRINT " if the called program is not on " 1740 PRINT " the disk in the default drive" 1750 RETURN Batch File for Demo: ECHO OFF ECHO . REM Display the system date DATE ECHO . REM Display the system time TIME :ENDPROG2 ----------------------------------------------------------------- BASIC Debugging (PC Magazine August 1986 User-to-User) BASIC is great for interactive programming, but its debugging tools are quite primitive. One of the most irritating limitations is that when you make a simple correction to a single line (even a REMark) BASIC flushes all your variables, closes all your files, and forces you to start the program over to test the correction. When the interpreter finds an error, it prints an error message and halts the program. In many cases, you could continue running the program if only you could re-enter the offending line and re-execute it. To make such on-the-fly corrections, examine the erroneous line with the LIST command. (The problem line will already be displayed if it contains a syntax error.) Then type the following command in direct mode: CHAIN MERGE "CON",ERL,ALL The cursor will drop down to the next line and wait for keyboard input. Next, rekey the bad line, and press Enter and then Ctrl-Z and then Enter again. The program will continue where it left off. The next time you list or save the program, it will contain the repaired program line. Another tip on smart BASIC debugging is to avoid error traps (ON ERROR GOTO) unless they are absolutely necessary. They tend to hide errors that need to be caught, and you will find yourself unable to get to the root of a malfunction. Programs can trap errors right at the source, and then turn error trapping off as soon as possible. For example: 100 'Print report 110 ON ERROR GOTO 130 120 GOTO 150 130 PRINT "Printer ERROR. Hit a key." 140 WHILE INKEY$="":WEND:RESUME 150 LPRINT "ABC Company Report" 160 ON ERROR GOTO 0 170 '...print rest of report .... This example assumes that any printer errors will surface during the printing of the first line of a report. The error trap itself resides directly above the possible error, and error trapping is on only during the printing of that line. Use a similar layout when opening files. Printer and disk I/O are about the only places that an error trap is really needed. You can write program code to test for any other potential problems without resorting to BASIC's error handling. Editor's Note: Using CHAIN MERGE "CON" to fix a BASIC problem without shutting down the active program is a handy trick. Your cursor may temporarily disappear while you're entering the new line, and you may have to hit the Esc key to erase a message on the screen before you type in the CHAIN MERGE... command, but the technique can save a tremendous amount ot time. Note that while this will correct the problem line in memory, be sure to save the file to disk to make the correction permanent. In the report-printing routine, you might want to test the error that BASIC catches with an IF ERR=25 THEN... or IF ERL=150 THEN... to make sure that the actual problem isn't falsely reported as a printer error when it's caused by something else. However, it is right to trap all the usual errors by writing thorough code, not by skimping on traps and waiting for a mistake to fall through to an ON ERROR statement. ----------------------------------------------------------------- Refreshing PAUSE (PC Magazine August 1986 User-to-User) To pause for a keystroke in BASICA, most programmers use either 10 A$=INEKY$:IF A$="" THEN 10 or 10 WHILE INKEY$:WEND A more natural way is to create a machine language subroutine at the beginning of your program and then call it whenever required. Simply insert the following code at the start of any program: 0 CLEAR,5888 1 DEF SEG=5888 2 FOR X.=0 TO 6 3 READ Y. 4 POKE X.,Y. 5 NEXT 6 PAUSE=0 7 DATA 80,180,7,205,33,88,203 and then adda a 100 CALL PAUSE (substituting the appropriate line number for the 100) whenever you want to wait for a keystroke. The example here takes up seven lines, but you can use colons to concatenate it all to a single line starting with 0 and save the line as an ASCII file, then merge this file into any of your existing programs. The X. and Y. variables and line number 0 are uncommon so that they don't interfere with ones already in your programs. The key you hit to break the pause is not stored in the keyboard buffer after the program execution continues. If you need to read the key, change the "7" to a "1" in the DATA statement in line 7. Editor's Note: This may be more natural than the usual methods, but it doesn't really work any better and won't compile as is. If you try it and do want the keystroke to print, after changing the 7 to 1 in the DATA statement, follow the CALL PAUSE with a 200 PRINT INKEY$ (substituting the appropriate line number for the 200). ----------------------------------------------------------------- Compaq Unprotection (PC Magazine August 1986 User-to-User) It's simple to modify the technique for unprotecting BASIC programs described in PC Mag Vol 4 No 25 User-to-User and PC Mag Vol 5 No 10 PC Tutor to work on non-IBM versions of BASIC. Instead of IBM's location 1124, use 1228 for Compaq BASIC 2.11, and 1433 for Compaq BASIC 3.11. If the location is included in the BSAVE ooperation, you may omit it from the BLOAD. Other non-IBM, non-Compaq versions of MS-BASIC may use entirely different locations. Editor's Note: "Protecting" a BASIC file by saving it with the ",p" option doesn't really do much other than prevent naive users from listing the source code. The technique to remove the flimsy protection is to get into BASIC and typing: BSAVE "UN.P",1124,1 (substituting location 1228 or 1433 if you're using Compaq BASIC 2.11 or 3.11, respectively). If you every try to list a BASIC program and see an "Illegal function call" message, just type: BLOAD "UN.P" At this point you should be able to list the source code. If not, make sure you tried the proper offset (1228 or 1433) for the BASIC version you're using. Then resave the formerly protected BASIC program to remove the effects of the ",p" permanently. ----------------------------------------------------------------- STRING$ and CHR$ (COMPUTE! Magazine September 1986) The statement PRINT STRING$(15,32) has exactly the same effect as PRINT " " (15 spaces). STRING$ can be used where any long series of identical characters is needed. For instance, PRINT STRING$(40,46) prints a line consisting of 40 dots. You can also do the same thing through concatenation. To create a string consisting of 30 spaces, for instance, use: SP$=" " FOR J=1 TO 30 SP$=SP$+CHR$(32) NEXT This construction is easy to type and requires only a few more characters than printing the string in literal form. ----------------------------------------------------------------- BASIC Configuration (PC World September 1986 Star-Dot-Star) A short BASIC program can define BASIC's function keys and then erase itself from memory. A short batch file can start BASIC and run this program automatically so that your custom function key assignments are in place. Defining the function key settings in this manner also lets you use the following time-saving trick. Whenever you write a BASIC program, always put a comment on line 1 beginning with the program's name enclosed in quotes. Combining this step with the F10 definition show in BSTART.BAS enables you to save a program anytime with one quick keystroke. The first part of F10's definition, "LIST 1"+CHR$(13), simply lists the first line of the current program -- the line containing the program's name. The two CHR$(30) characters move the cursor back to the beginning of the listed line. SAVE overwrites the line number and the apostrophe, leaving the file name in quotation marks intact. The last CHR$(13) simulates pressing Enter, executing the SAVE command using the supplied file name. This technique should be a boon to anyone who issues SAVE commands frequently, since it reduces that task to a single keystroke. If you prefer to save your programs in ASCII format you can place the ,A after whatever file name you specify. ----------------------------------------------------------------- IBM Custom Characters (COMPUTE! Magazine September 1986) You can redefine the character set on the IBM PC; however, there are a couple of restrictions. Redefined characters must be printed on one of the graphics screens to be seen, and only the upper half of the character set (characters 128-255) can be changed. The following program shows how to redefine CHR$(128) as an alien shape. It displays the custom character on SCREEN 1. 10 DEF SEG=0 20 POINTER=&H7C 'POINTER &H110 for characters 0-127 on the PCjr only 30 FOR VECTOR=0 TO 3:OLDVEC(VECTOR)=PEEK(POINTER+VECTOR):NEXT 40 DEF SEG=&H1700 50 FOR DOTPOS=0 TO 7:READ DOT DATA:POKE DOTPOS,DOTDATA:NEXT 60 DEF SEG=0: 70 SCREEN 1:CLS 80 FOR VECTOR=0 TO 2:POKE(POINTER+VECTOR),0:NEXT:POKE POINTER+3,&H17 90 PRINT CHR$(128) 100 FOR VECTOR=0 TO 3:POKE(POINTER+VECTOR),OLDVEC(VECTOR):NEXT 110 DATA 60,126,90,126,60,36,66,129 You make the computer look to RAM rather than ROM for its character data. If you have at least 128K of RAM in your PC, memory above 96K is unused by BASIC and is thus a safe place to store the custom character data. Line 40 of the program accesses this area with the statement DEF SEG=&H1700. In line 50, the program puts the alien shape data in the area beginning at &H1700. Line 110 contains the data. To make the PC fetch its character data from the segment at &H1700, we must change certain pointers at the bottom of memory. These pointers are four bytes long. The first two bytes represent an offset to the segment address contained in the third and fourth bytes. The pointer to the data for the built-in graphics and foreign language characters (numbered 128-255) is at locatino &H7C. Since the program redefines a character in this range -- CHR$(128) -- we've used this pointer value in line 20. On the PCjr, you can redefine characters in the range 0-127 using the pointer at location &H110. In order to access either character data pointer, you must set DEF SEG to zero since the pointers are at the bottom of memory. The program does this in lines 10 and 60. Before the program ends, the character data pointers must be restored to their default values. If you end the program with the character pointers still modified, the computer can't recognize the custom characters and will fail to respond to any commands. Before modifying the characters, save the default character set pointers (line 30). When you're done printing the custom characters, restore the pointers to their original values (line 100). ----------------------------------------------------------------- Identifying Displays (PC Magazine Vol 5 No 16 Sept 30, 1986 PC Tutor) A user develops applications with the BASIC interpreter and compiles them with Microsoft QuickBASIC. He uses a technique to blank the screen while text is being written to it. This results in a nice, professional-looking video screen that flashes on all at once, rather than visibly being drawn one line at a time. To turn the display off, use the statement: OUT 984,1 and to turn it back on: OUT 984,41 This works perfectly with an IBM or compatible color graphics adapter. The problem is that the programs must also run on some Hercules Graphics Cards (and Hercules clones), and the technique doesn't work with these boards. Different video pages are also used in the programs, and these, too, are ignored by the Hercules card. Editor's Note: This technique won't work on regular IBM Mono Adapters, either. The port being manipulated is the "Mode Control Port Register," which has a different address on color adapters and monochrome adapters, including the Hercules Graphics Card. The Control Port for monochrome displays is at address 952 rather than 984. (In hex, these addresses are 3B8 and 3D8.) You can blank an IBM Monochrome Adapter or Hercules Card with: OUT 952,1 and unblank it with: OUT 952,41 but that's not the best way to do it. The control port address is always 4 higher than the I/O address of the 6845 video chip. That port address is a word (2 bytes) stored at the hex address 0040:0063 in the BIOS data area. So, you can define a variable for the Control Port thus: DEG SEG=&H40 CTRLPORT=4+256*PEEK(&H64)+PEEK(&h63) Now you can simply use the variable CTRLPORT instead of 984 or 952. You won't be able to use separate video pages on an IBM Monochrome Adapter or the Hercules Graphics Card, however; so unless you want to write alternative code for the monochrome boards, it's easier to avoid using video pages altogether. (If you must use video pages, you can still use the value of CTRLPORT to also identify the type of adapter.) In general, however, the best way for your programs to identify the video display is to ask the user on-screen. This is nothing to be ashamed of. You'll find that most software that does anything beyond plain vanilla text output requires some sort of installation program. Some really big-league stuff like Microsoft Word can adapt to different displays without being told, but then we're talking about a 44K WORD.COM program (version 3.0) that identifies displays and provides drivers for them. We're also talking about problems by experts in the field. Further, we're about to see a real explosion in video adapters, and it's going to get tougher and tougher to write programs that work with all of them. The EGA is just the beginning. (The above technique of blanking the screen won't work on an EGA, but it won't do any harm, either.) This is one reason why the graphics device interface of Microsoft Windows is so important to the future of the PC. Windows takes on the responsibility of dealing with the hardware so that you can concentrate on the program. ----------------------------------------------------------------- BSAVE Image Arrays to Disk (PC World October 1986 The Help Screen) Recording a BASIC image array in a disk file and reading that file to set an image variable is simpler than using GET and PUT. To save an image array to disk, issue the DEF SEG statement to set BASIC's data segment as the current memory segment, and execute the BSAVE (binary save) command. The BSAVE command, which saves any portion of memory to disk, requires three parameters: the filespec of the file being saved, the offset (number of bytes) into the current memory segment where the first byte of data representing the image begins, and the number of bytes to be saved. The filespec requires a file name, but it can include a drive specifier and, with BASIC 2.0 and later versions, a path. The offset should point to the beginning of the image array variable. You accomplish this by specifying the array's first element, (0), with the VARPTR function. You already know the size of the variable array because you had to calculate the number of bytes that the image array required to properly DIMension the array. In this example, the image is 34 bytes. Because a single-precision array dedicates 4 bytes per element, a nine-element array will reserve sufficient space. BSAVE.BAS also demonstrates how to load a saved image array. Issue a DEF SEG statement to set BASIC's data segment as the current memory segment, then execute the BLOAD (binary load) command to put the image data into memory. BLOAD requires just two parameters: the filespec and the offset of the current memory segment where the image file should be placed. Point to the beginning of the image array variable with the aid of the VARPTR function. BSAVE.BAS: 10 SCREEN 1:CLS 20 LINE (0,0)-(10,10),3,B 30 CIRCLE (5,5),5,1 40 PAINT (5,5),2,1 50 DIM IMAGE(22) 60 GET (0,0)-(10,10),IMAGE 70 DEF SEG 80 BSAVE "IMAGE.FIL",VARPTR(IMAGE(0)),88 90 ERASE IMAGE 100 DIM IMAGE(22) 110 DEF SEG 120 BLOAD "IMAGE.FIL",VARPTR(IMAGE(0)) 130 PUT (100,100),IMAGE 140 LOCATE 13 ----------------------------------------------------------------- Personalized DATA (PC Magazine Vol 5 No 20 Nov 25, 1986 User-to-User) STAMP.BAS (PC Mag Vol 5 No 8 April 29, 1986) demonstrated how to modify a comment permanently from within a BASIC program. It's also possible to modify a quoted string in an assigned statement or DATA statement, since the BASIC interpreter will set up the string variable to point into the program itself when the string is assigned to, or read to, a string variable. UPDATER.BAS asks for the user's name, displaying the name that is already loaded in the DATA statement as the default. If the user then simply hits the Return key, the program accepts the default; otherwise the program stores the replacement name in the DATA statement and then saves itself. CVI is used to for the string, since this technique avoids possible overflow errors that can result from multiplication. Editor's Note: This kind of trick can come in handy when adding new information on the fly, but be careful with it since it can also write bad data over good data. You can get around this by adding a line to the program that saves a backup "UPDATER.BAK" file to disk before it makes any of the changes in memory and then writes the permanently changed file. 100 'UPDATER.BAS 110 READ DUMMY$ 120 PRINT "Enter your name: [";DUMMY$;"]" 130 LINE INPUT I$ 140 IF I$="" THEN END ELSE I$=I$+SPACE$(19) 150 P%=VARPTR(DUMMY$) 160 L%=PEEK(P%) 170 A%=CVI(CHR$(PEEK(P%+1))+CHR$(PEEK(P%+2))) 180 FOR I%=1 TO L% 190 POKE A%+I%-1,ASC(MID$(I$,I%)) 200 NEXT 210 SAVE "UPDATER 220 DATA "User name goes here" ----------------------------------------------------------------- BASIC and the Environment (PC Magazine Vol 5 No 20 Nov 25, 1986 PC Tutor) You can use the undocumented feature of batch files that allows treating environment strings as replaceable parameters. With this you can let batch files know which device drivers are currently loaded and to prevent running incompatible resident programs. For instance, to load a mouse driver, your AUTOEXEC.BAT file can execute: SET MOUSE=1 Then you can do things in batch files like: IF "%MOUSE%"="1" some command IF NOT "%MOUSE%"="1" some other command Getting at the environment in BASIC is different. Editor's Note: This is a good use of the environment, except it doesn't work right under DOS 3.0. DOS 2.x, 3.1 and 3.2 handle it fine. The segment address of the environment is always stored at offset &H002C of the Program Segment Prefix (PSP) of any program. So, if you could find the segment address of BASICA.COM's PSP (which will be different depending on which resident programs and device drivers were loaded), you could directly access the environment with PEEK. This would be messy and probably involve some assembly language routines. There's a better way, and that is to upgrade to DOS 3.1 or later. The new BASICA 3.0 ENVIRON$ function retrieves strings from the environment based either on the parameter name (such as "PATH") or on a number. The small program below shows both approaches. The WHILE loop in the first part displays the same information as the DOS SET command executed without parameters. 10 I=1 20 WHILE ("" <> ENVIRON$(I)) 30 PRINT ENVIRON$(I) 40 I=I+1 50 WEND 60 PRINT "The COMSPEC is ";ENVIRON$("COMSPEC") ----------------------------------------------------------------- Doing a DIR in BASIC (PC Magazine Vol 5 No 20 Nov 25, 1986 PC Tutor) How do you read a diskette directory information into an array from a BASIC program, and how do you invoke a Print-Screen from within a program automatically? Editor's Note: A very common method used by BASIC programmers for reading the directory is no more elegant than: 1) Clear the screen with CLS 2) Do a FILES command to display a directory on the screen 3) Read the information off the screen character by character with a combination of the LOCATE statement and teh SCREEN function. (The SCREEN function reads characters from the screen; there is also a SCREEN statement used for setting video modes.) If you'd rather not have the users of your program know what you're doing, you can use the COLOR statement to set the same foreground and background colors so nobody can see the FILES display. (The information is still there, of course.) You might also consider another method using the SHELL command, which is documented under BASIC 3.0 and works most of the time under BASIC 2.0. The SHELL command executes another program or a DOS command from BASIC. Your line would read: SHELL ("DIR > DIRLIST") This puts a normal DIR listing into a file called DIRLST. You can then read the DIRLIST file normally and extract the information you want. Other than these approaches, you'd probably have to use an assembly language subroutine. This would definitely be more complex than either of the two methods described above. BASIC is not the only high-level language that has no built-in facility for obtaining directory information: Turbo Pascal and Microsoft C 3.0 don't either. Doing a Print-Screen from a BASIC program is much easier. In fact, the BASIC 3.0 manual shows two methods for doing it in Appendix B on assembly language subroutines. The BIOS Print Screen routine is invoked by an Interrupt 5, which in assembly language takes just two bytes: &HCD and &H05. An assembly language routine in BASIC needs only one more byte, an &HCB, which is a far return back to the main BASIC program. You can determine the bytes needed for an assembly language routine by going into DEBUG assemble mode with the A command and typing: INT 5 RETF and then listing the bytes with the D command. To get these bytes into a BASIC listing, first DIMension an integer array and store the assembly language code in it: 10 DIM APRTSC%(2) 20 APRTSC%(1)=&H05CD 30 APRTSC%(2)=&H90CB Each integer can store 2 bytes. (Note that the integers are stored in reverse order, with the most significant byte higher in memory.) The extra &H90 at the end is a NOP instruction, which does nothing. After the array is set up, use the VARPTR function to find the address of the array in memory and store it in another variable: 40 PRTSC%=VARPTR(APRTSC%(1)) Now you need only CALL that variable: 50 CALL PRTSC% and your screen will be printed. ----------------------------------------------------------------- IBM PC One-Liner (COMPUTE! December 1986 by Paul W. Carlson) Programs don't have to be long to be useful. The one-line program below can be used to entertain pre-schoolers, while teaching them the alphabet and the computer's keyboard at the same time. Adults can benefit from the program by gaining an increased understanding of how characters are produced on the IBM's video display. However it's used, the program is certainly worth the time it takes to type in the single line. When you run it, nothing seems to happen. Now press any key on the keyboard. A giant character matching the key you pressed rises from the bottom of the screen and centers itself on the display. Press another key. The same thing happens and continues happening until you press Ctrl-Break. The program enlarges all the letters (uppercase and lowercase), symbols, and punctuation that appears on the keyboard -- plus a few that don't appear on the keycaps. If you press Ctrl along with a letter or number key, you'll see one of the IBM's graphics characters. Even the function keys produce results. Try pressing F1. Despite its small size, the program contains some techniques you may find useful in other programs. 1. The program begins by setting the segment to location $FFA6. This is 14 bytes before the PEL (character definition) map in ROM. The program reads your keystroke and converts it to the corresponding ASCII code. 2. Then the program loops through eight bytes for the character, with byte zero (the first byte) containing the bits for the top row of the character and byte seven containing those for the bottom row. It stores the value of the PEL map in the variable A and initializes A$ as a null string. 3. We begin to loop through the eight bits of the current byte, resting the rightmost bit first. The variable M equals one if the bit is set and equals zero if it's not. The value of the variable W equals 32 (the ASCII code for a blank space) if the bit is not set and equals 219 (the ASCII code for a solid block) if the bit is set. Either three blanks or three solid blocks are added to the beginning of A$. Then the program shifts all bits in the current byte by subtracting the value of the rightmost bit and dividing by two. This step is repeated for each bit of the current byte. 4. The next step is to print A$ preceded by 28 blanks. This is done twice to double the character's height. Then the program branches back to step 2 and repeats the process for each byte of the PEL map that defines the character. After the last byte of the PEL map has been processed, we print two blank lines and return to step 1 to wait for another keypress. Experienced programmers may notice that the code could be made even more compact. Some statements could be combined, but this would result in parentheses several levels deep, making the program more difficult to understand. 1 KEY OFF:DEF SEG=&HFFA6:L$=INPUT$(1):N=ASC(L$):CLS:LOCATE 24,1,0:FOR L=0 TO 7:A=PEEK(N*8+L+14):A$="":FOR J=0 TO 7:M=A AND 1:W=32+M*187:A$ =CHR$(W)+CHR$(W)+CHR$(W)+A$:A=(A-M)/2:NEXT J:PRINT SPC(28)A$:PRINT SPC(28)A$:NEXT L:PRINT:PRINT:GOTO 1 (NOTE: To save and run this one-line program, copy it out and make it one continuous line by removing the carriage returns from the ends of the lines.) ----------------------------------------------------------------- Faster Slide Show (PC Magazine Vol 5 No 21 Dec 9, 1986 User-to-User) This technique produces a smooth BASIC slide show program. The BASIC BLOADer normally reads a graphics screen off a disk directly to the screen buffer. This approach gives a very slow (7.5-second) and messy screen update. However, using a combination of the PUT statement and VARPTR function with BLOAD creates a fast and smooth slide show program. Use these statements to create screen data files: 100 DIM A(4000) . . (Screen-creating code) . 200 GET (0,0)-(319,199),A 210 DEF SEG 220 ADDRESS=VARPTR(A(0)) 230 BSAVE "SCR1.",ADDRESS,16004 Then use the following statements to display the graphics screens: 100 DIM A(4000) 110 ADDRESS=VARPTR(A(0)) 120 BLOAD "SCR1.",ADDRESS 130 PUT (0,0),A,PSET This method updates the screen in less than a second. It still takes about 7.5 seconds to BLOAD the graphics information into memory, but you can display one screen while the next one loads. The full technique is implemented in DEMOLOAD.BAS: 100 'DEMOLOAD.BAS 110 DEF FNS$(Z)=MID$(STR$(Z),2) 120 SCREEN 1:CLS:KEY OFF:DIM A(4000) 130 PRINT "First we'll make 3 screens" 140 PRINT "(Hit any key to continue)" 150 WHILE INKEY$="":WEND:CLS 160 FOR B=1 TO 3:FOR C=1 TO 23 170 PRINT STRING$(40,48+B);:NEXT 180 CIRCLE (160,92),60,B,,,4/5 190 PAINT (160,92),B 200 GET (0,0)-(319,199),A 210 DEF SEG:ADDRESS=VARPTR(A(0)) 220 BSAVE "SCR"+FNS$(B),ADDRESS,16004 230 CLS:NEXT 240 ' 250 PRINT "Now we'll quick-load them" 260 PRINT "(Hit any key to continue)" 270 WHILE INKEY$="":WEND 280 ADDRESS=VARPTR(A(0)) 290 BLOAD "SCR1",ADDRESS 300 PUT (0,0),A,PSET 310 BLOAD "SCR2",ADDRESS 320 PUT (0,0),A,PSET 330 BLOAD "SCR3",ADDRESS 340 PUT (0,0),A,PSET ----------------------------------------------------------------- BASICA 3.2 Bug (PC Magazine Vol 5 No 22 Dec 23, 1986 User-to-User) DOS 3.2 BASICA.COM does not save files efficiently. If a file's size is reduced, the space allocated is fixed at the largest previously saved size. This is not true for all other IBM (Microsoft) BASICs, including DOS 3.2 BASIC.COM. The solution is to set up a macro (based on the filename being imbedded in the program at a fixed location) to first delete the current file before the updated version is saved. SmartKey is a big help here. Editor's Note: Another solution is to add two lines to the beginning of your program: 101 KILL"filename 102 SAVE"filename (substituting the actual name of your BASICA program for filename). Each time you run it, this code will delete the existing version and save the subsequent one. Actually, when you chop a large program down to a smaller one, BASICA 3.2 not only keeps the file size the same but actually seems to retain the discarded part of the program. To see this in action (assuming you're using BASIC 3.2 only), run LONG.BAS to create a 10K file: 100 'CREATE.BAS -- creates a long file 110 DEF FNST$(Z)=MID$(STR$(Z),2+(Z<0)) 120 OPEN "LONG.BAS" FOR OUTPUT AS #1 130 FOR A=100 TO 5000 STEP 10 140 PRINT #1,FNST$(A);" REM DUMMY TEXT" 150 NEXT:CLOSE:END Get into DOS and note the file size. Then get into BASICA 3.2, load LONG.BAS, and issue the command to get rid of most of the file's contents: DELETE 200- Save the shorter file, and get into DOS and you'll see that the tiny file has the same size as the older, larger one. Then get into DEBUG, and start leaning on the D key and you'll see that the part of the file you deleted is still there.